home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20010306-20010921 / 000076_news@columbia.edu _Mon Apr 23 09:03:20 2001.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA22832
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Mon, 23 Apr 2001 09:03:20 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id JAA04645
  7.     for kermit.misc@watsun.cc.columbia.edu; Mon, 23 Apr 2001 09:01:34 -0400 (EDT)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. Message-ID: <3AE4279A.267247FE@macrotex.net>
  10. From: "Adam H. Lewenberg" <adam@macrotex.net>
  11. Subject: Re: Secure File transfer Please reply via email
  12. Date: Mon, 23 Apr 2001 08:01:14 -0500
  13. Organization: University of Illinois at Urbana-Champaign
  14. To: kermit.misc@columbia.edu
  15.  
  16. I think (by now) we have got the message that some 
  17. of the Kermit developers are not enamored with ssh
  18. and even have good technical reasons for holding their
  19. negative opinions of this product.
  20.  
  21. But the security arguments miss the point: the
  22. vast majority of users who need telnet support have
  23. no secure connection choice other than ssh. It would
  24. be nice if all (or even many) of the sysadmins
  25. around the world installed a better security product
  26. but they haven't and probably won't: ssh is 
  27. just too easy. 
  28.  
  29. The alternative---unencrypted telnet connections---
  30. will soon vanish as sysadmins turn off these ports.
  31.  
  32. So, I hope that the Kermit development folks can
  33. swallow their disappointment that VHS 
  34. is prevailing over BETA and make the ssh client
  35. version of Kermit and Kermit95 available as soon as
  36. possible. The Kermit platform is unequalled
  37. in essenatially every other way (terminal emulation,
  38. scripting, etc.) and it would be a shame to see
  39. it languish because people are forced to use
  40. some inferior ssh client. 
  41.  
  42. Respectfully yours, A. Lewenberg
  43.  
  44. Frank da Cruz wrote:
  45. > In article <4416878.EvYhyI6sBW@ac.lisse.na>,
  46. > Eberhard W Lisse  <el@lisse.NA> wrote:
  47. > : On Tuesday 17 April 2001 20:23 Michael Witherington wrote:
  48. > : > I need to initiate a secure file transfer from a linux machine using
  49. > : > C-Kermit 6.0.192 to a windows machine running Kermit 95.
  50. > :
  51. > : ssh
  52. > :
  53. > No, believe it or not, ssh is not the answer to every question.  Michael
  54. > worded his question carefully, specifying the software and versions that
  55. > he has available, which happen to be scattered over hundreds locations.
  56. > The real answer is: there is no way to accomplish secure transfers using
  57. > the software combinations that he has available, not without installing
  58. > additional software of some kind (something he did not wish to do because
  59. > of the many scattered sites).  Since additional software must be installed,
  60. > it might as well be C-Kermit 7.0 (or soon 7.1) which supports the same
  61. > security methods as the current Kermit 95 release.  These are described
  62. > here:
  63. >   http://www.columbia.edu/kermit/security.html    <-- C-Kermit 7.0
  64. >   http://www.columbia.edu/kermit/security71.html  <-- C-Kermit 7.1
  65. > Also, as noted previously, we do not believe SSH is a particularly safe
  66. > or reliable security method compared to the ones supported by Kermit,
  67. > which are Kerberos 4 and 5, SSL/TLS, and SRP.  Some of the reasons are
  68. > listed here:
  69. >   http://www.columbia.edu/kermit/ckfaq.html#ssh
  70. > This does not mean we won't be adding SSH 2 (and maybe 1) support in
  71. > future Kermit releases.  The requests for it have been defeaning and
  72. > arguments against it are futile.  But if we do add it, we will describe
  73. > the pitfalls in the documentation rather than painting it as some kind of
  74. > ultimate security solution.
  75. > - Frank
  76.  
  77. -- 
  78. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  79. Adam Lewenberg  (217) 373-8173 voice and fax
  80. adam@macrotex.net
  81.